Amazon Aurora MySQL 5.6を頑張らずに8.0へメジャーアップグレードしてみた

Amazon Aurora MySQL 5.6を頑張らずに8.0へメジャーアップグレードしてみた

Clock Icon2022.11.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2023年2月末にEOLを迎えるMySQL5.6互換のAmazon Aurora MySQL v1を8.0互換のv3にメジャーアップグレードする機会がありましたので共有します。

  • 小規模な社内システム
  • 日程を調整すれば長時間停止可能
  • アプリケーションはMySQL 8.0環境で十分に動作確認済み

という前提の元、数時間のメンテナンス時間中にインプレース・アップグレード方式で極力頑張らずにメジャーアップグレードしました。

Aurora MySQLメジャーバージョンアップグレードの背景

Aurora MySQLは1〜3の3バージョンが存在し、今回移行したMySQL 5.6互換のv1は2023年2月28日にEOLを迎えます。

Amazon Aurora MySQL v1サポート終了のタイムラインは以下の通りです。

  • 2022年9月27日より AWS コンソール、CLI、SDK から V1(5.6) の新規インスタンス不可
  • 2023年3月1日より V1(5.6) から V2(5.7) への自動アップグレードが開始

更には、MySQL5.7互換のv2も2024年10月31日にEOLを迎えます。

Auroraバージョン LTS MySQLバージョン 新しいAuroraバージョンへの
アップグレード予定日
Community Edition側の
Extendedサポートの終了予定
1 1.22.* 5.6 2023年2月28日 2021年2月5日
2 2.07.* 5.7 2024年10月31日 2023年10月21日
3 未発表 8.0 未発表 2026年4月

短期間に2回に分けてメジャーアップグレードするよりも1回で済ませたほうが効率的であり、アプリケーション開発者がMySQL 8.0環境で動作確認を豊富に行っていたことから、v1(5.6)からv3(8.0)への2段階のメジャーアップグレードを実施しました。

メジャー・アップグレード方法

今回は次の3方式を検討しました。

移行方法 ダウンタイム 手順 切り戻し DBエンドポイント
インプレース 長い シンプル スナップショット 同じ
ダンプ&リストア 普通 普通 旧環境に切り戻す 変わる
レプリケーション 短い 複雑 旧環境に切り戻す 変わる
  • 小規模システムであること
  • 長いメンテナンス時間を確保できること
  • 単純・明快な方法が好まれること

といった点から インプレース方式を採用しました。

インプレース方式

AWSのマネージド機能をフル活用し、クラスターを直接メジャーアップグレードします。

コンソールからボタンポチで作業が完結する一方で、マイグレートには比較的時間がかかります。

切り戻し時には、マイグレート前に作成されるスナップショットを利用します。

ダンプ & リストア方式

移行先バージョンのクラスターを作成し、mysqldump 等を利用してクラスター間でデータをエクスポート&インポートします。

弊社の技術ブログ・サイト Developers.IO を v2 から v3化(ついでに Aurora Serverless v2化)した際は、この方式を採用しました。

Aurora2(MySQL5.7互換)のDB環境をAurora3(MySQL8.0互換)へアップグレードしてみた | DevelopersIO

データ量に応じてエクスポート・インポート時間も伸びます。

レプリケーション方式

移行先バージョンのクラスターを作成し、binlog レプリケーションでクラスター間でデータ同期し、最後にスイッチオーバーします。

手順は複雑ですが、データ量に関係無く短いダウンタイムで切り替えられるのが最大の特徴です。

2022年11月末にこのプロセスをマネージドで行うBlue/Green機能がリリースされ、採用の敷居が下がりました。

5.6から8.0へのインプレース・メジャーアップグレードの流れ

最終的には以下の流れで実施しました

  1. クラスターのCloneを作成(切り戻し目的)
  2. 5.6 から 5.7 へインプレースアップグレード
  3. インスタンス・タイプを変更
  4. 5.7 から 8.0 へインプレースアップグレード

AWSコンソールから数回ポチポチするだけです。

手順について、一部補足します。

切り戻し対応

アップグレードプロセスやアップグレード後の動作確認で問題が発生したときの切り戻し方法です。

インプレースアップグレードを実行すると、アップグレード前にスナップショットが作成されます。このスナップショット利用すると、アップグレード前のデータ、及び、データベースバージョンのクラスターをリストアできます。

今回は、問題発生時に速やかに切り戻したかったため、クラスターをコピーするクローン機能を活用して切り戻し先としました。

アップグレード可能なバージョン

Aurora MySQL はv1からv3へ一度にメジャーアップグレードできません。

また、エンジンバージョンごとにアップグレード可能なバージョンが存在します。

API aws rds describe-db-engine-versions で対応するバージョンを確認できます。

$ aws rds describe-db-engine-versions \
  --engine aurora \
  --engine-version 5.6.mysql_aurora.1.22.2  \
  --query 'DBEngineVersions[].ValidUpgradeTarget[].{IsMajorVersionUpgrade:IsMajorVersionUpgrade,EngineVersion:EngineVersion}' \
  --output table

------------------------------------------------------
|              DescribeDBEngineVersions              |
+--------------------------+-------------------------+
|       EngineVersion      |  IsMajorVersionUpgrade  |
+--------------------------+-------------------------+
|  5.6.mysql_aurora.1.22.3 |  False                  |
|  5.6.mysql_aurora.1.22.4 |  False                  |
|  5.6.mysql_aurora.1.22.5 |  False                  |
|  5.6.mysql_aurora.1.23.0 |  False                  |
|  5.6.mysql_aurora.1.23.1 |  False                  |
|  5.6.mysql_aurora.1.23.2 |  False                  |
|  5.6.mysql_aurora.1.23.3 |  False                  |
|  5.6.mysql_aurora.1.23.4 |  False                  |
|  5.7.mysql_aurora.2.07.1 |  True                   |
|  5.7.mysql_aurora.2.07.1 |  True                   |
|  5.7.mysql_aurora.2.07.3 |  True                   |
|  5.7.mysql_aurora.2.07.4 |  True                   |
|  5.7.mysql_aurora.2.07.5 |  True                   |
|  5.7.mysql_aurora.2.07.6 |  True                   |
|  5.7.mysql_aurora.2.07.7 |  True                   |
|  5.7.mysql_aurora.2.07.8 |  True                   |
|  5.7.mysql_aurora.2.09.1 |  True                   |
|  5.7.mysql_aurora.2.09.2 |  True                   |
|  5.7.mysql_aurora.2.09.3 |  True                   |
|  5.7.mysql_aurora.2.10.0 |  True                   |
|  5.7.mysql_aurora.2.10.1 |  True                   |
|  5.7.mysql_aurora.2.10.2 |  True                   |
|  5.7.mysql_aurora.2.10.3 |  True                   |
|  5.7.mysql_aurora.2.11.0 |  True                   |
+--------------------------+-------------------------+

$ aws rds describe-db-engine-versions \
  --engine aurora-mysql \
  --engine-version 5.7.mysql_aurora.2.11.0  \
  --query 'DBEngineVersions[].ValidUpgradeTarget[].{IsMajorVersionUpgrade:IsMajorVersionUpgrade,EngineVersion:EngineVersion}' \
  --output table

------------------------------------------------------
|              DescribeDBEngineVersions              |
+--------------------------+-------------------------+
|       EngineVersion      |  IsMajorVersionUpgrade  |
+--------------------------+-------------------------+
|  8.0.mysql_aurora.3.01.1 |  True                   |
|  8.0.mysql_aurora.3.02.0 |  True                   |
+--------------------------+-------------------------+

Aurora MySQL v3の最新バージョンは 3.02.1 ですが、インプレースのメジャーアップグレード先として選択可能な最新バージョンは一つ下の 3.02.0 です。

v3系の最新版へアップグレードしたい場合は、3.02.0 へのメジャーアップグレード後に、 3.02.1 へマイナーアップグレードしてください。

Aurora MySQL 1.22.2 以下のバージョンからのインプレースアップグレードは時間がかかる

Aurora MySQL 1.22.2 以下のバージョンからインプレースでメジャーアップグレードを実行すると、一度 1.22.3マイナーアップグレードしたあとで v2 系へメジャーアップグレードします。

ダウンタイムを短縮したい場合は、事前に 1.22.3 以上へマイナーアップグレードしておきましょう。

インスタンスタイプを変更

エンジンバージョンごとに対応しているインスタンスタイプが異なります。

API aws rds describe-orderable-db-instance-options で対応するインスタンスタイプを確認できます。

Aurora 3.02.0 が対応するタイプを確認してみましょう。

$ aws rds describe-orderable-db-instance-options \
  --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.02.0 \
  --query 'OrderableDBInstanceOptions[].DBInstanceClass'
[
    "db.r5.12xlarge",
    "db.r5.16xlarge",
    "db.r5.24xlarge",
    "db.r5.2xlarge",
    "db.r5.4xlarge",
    "db.r5.8xlarge",
    "db.r5.large",
    "db.r5.xlarge",
    "db.r6g.12xlarge",
    "db.r6g.16xlarge",
    "db.r6g.2xlarge",
    "db.r6g.4xlarge",
    "db.r6g.8xlarge",
    "db.r6g.large",
    "db.r6g.xlarge",
    "db.serverless",
    "db.t3.large",
    "db.t3.medium",
    "db.t4g.large",
    "db.t4g.medium"
]

今回利用した各バージョンが対応しているタイプは下記表の通りです。

インスタンスタイプ v1(1.22.2) v2(2.11.0) v3(3.02.0)
db.serverless
db.r3.2xlarge
db.r3.4xlarge
db.r3.8xlarge
db.r3.large
db.r3.xlarge
db.r4.16xlarge
db.r4.2xlarge
db.r4.4xlarge
db.r4.8xlarge
db.r4.large
db.r4.xlarge
db.r5.12xlarge
db.r5.16xlarge
db.r5.24xlarge
db.r5.2xlarge
db.r5.4xlarge
db.r5.8xlarge
db.r5.large
db.r5.xlarge
db.r6g.12xlarge
db.r6g.16xlarge
db.r6g.2xlarge
db.r6g.4xlarge
db.r6g.8xlarge
db.r6g.large
db.r6g.xlarge
db.t2.medium
db.t2.small
db.t3.large
db.t3.medium
db.t3.small
db.t4g.large
db.t4g.medium

v2から r6g や t4g の Graviton 系に対応し、v3では r4や t2のインスタンスクラスや small サイズに対応しなくなったことがわかります。

当該環境は t3.small を使っていたため、v1からv2にアップグレードしたタイミングで t4g.medium へインスタンスタイプを変更し、その後v3へアップグレードしました。

大きく変動するワークロードを扱っている場合、オンデマンドでキャパシティが変動する Aurora Serverless v2(db.serverless) を検討してもいいでしょう。 ピーク時に合わせてサイジングしなくてすむため、利用費の軽減を期待できます。

検証について

メジャーバージョン間の機能差異

メジャーバージョン間の機能差異は以下のドキュメントにまとまっています。

5.7から8.0への移行では、機能面・性能面などで問題が見つかる事が多いです。

検証環境を用意し、移行前に十分に新しいメジャーバージョンを評価してください。

5.6クラスターをどうやって作成する?

2022年9月27日以降はv1(5.6互換)クラスターを新規に作成できなくなりましたが、スナップショットからリストアすることは可能です。 スナップショットから検証用クラスターを作成しましょう。

暗号化されているスナップショットをクロスアカウント共有する際には、鍵の共有も必要です。 次のドキュメントを参照ください。

暗号化された Amazon RDS スナップショットを別のアカウントと共有する

AWSのアップデートによって移行手順も随時変わる

AWSでは頻繁にアップデートがあるため、臨機応変に移行手順も調整しましょう。

2022年の8月からAurora MySQL EOL対応の検討をはじめたあと、以下アップデートで移行手順変更の判断が必要でした。

  • v2(5.7)からv3(8.0)へのインプレースアップグレードに対応
  • v2(5.7)のEOLが2024年2月29日から2024年10月31日に延長

v2からv3へのインプレースに対応する前は、スナップショットでv3クラスターを新規に立ち上げる予定でした。 前者のアップデートのおかげでアップグレード手順がよりシンプルになり、既存クラスターを使い回せるようになったため、アプリケーションの設定変更も不要になりました。

後者については、EOL が大幅に伸びたわけではないため、一度に2回メジャーアップデートする方針を踏襲しました。

アップグレード対応後の2022年11月末にはBlue/Greenデプロイメント機能がリリースされました。現時点では有力な移行手順の一つでしょう。

まとめ

Amazon Auroraのインプレース・アップグレード機能を活かし、EOLを控えた Aurora MySQL v1(5.6互換)を簡単・安全にMySQL 8.0互換の v3にメジャーアップグレードしました。

データサイズが小さい、長いメンテナンス時間を確保できる、などインプレース・アップグレード向けの好条件が揃っていたのが大きいです。

本記事では、AWSリソース観点の作業を中心に記載しました。

アップグレード手順が極めてシンプルだったおかげで、ステークホールダーとのコミュニケーション・コストを大きく引き下げることができ、プロジェクトを円滑に進められました。

頑張らないって、大事ですね。

参考:手順別の所要時間

各ステップにかかった時間を参考情報として共有します。

処理時間が一番短かったスナップショットの作成を1としています。

移行先行事例

参考

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.